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Modes of Operation for Camellia for Use with IPsec 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 
Please review these documents carefully, as they describe your rights 
and restrictions with respect to this document. 


Abstract 


This document describes the use of the Camellia block cipher 
algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, 
and Counter with CBC-MAC (CCM) mode as additional, optional-to- 
implement Internet Key Exchange Protocol version 2 (IKEv2) and 
Encapsulating Security Payload (ESP) mechanisms to provide 
confidentiality, data origin authentication, and connectionless 
integrity. 
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1. Introduction 


This document describes the use of the Camellia block cipher 
algorithm [1] in Cipher Block Chaining (CBC) mode, Counter (CTR) 
mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- 
implement IKEv2 [2] and Encapsulating Security Payload (ESP) [3] 
mechanisms to provide confidentiality, data origin authentication, 
and connectionless integrity. 


Since optimized source code is provided under several open source 
licenses [9], Camellia is also adopted by several open source 
projects (OpenSSL, FreeBSD, Linux, and Firefox Gran Paradiso). 


The algorithm specification and object identifiers are described in 
[ile 


The Camellia web site [10] contains a wealth of information about 
Camellia, including detailed specification, security analysis, 
performance figures, reference implementation, optimized 
implementation, test vectors, and intellectual property information. 


The remainder of this document specifies the use of various modes of 
operation for Camellia within the context of IPsec ESP. For further 
information on how the various pieces of IPsec in general and ESP in 
particular fit together to provide security services, please refer to 
[11] and [3]. 
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1.1. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 


document are to be interpreted as described in [4]. 


2. The Camellia Cipher Algorithm 
All symmetric block cipher algorithms share common characteristics 
and variables, including mode, key size, weak keys, block size, and 
rounds. The relevant characteristics of Camellia are described in 
[3-3 

2.1. Block Size and Padding 


Camellia uses a block size of 16 octets (128 bits). 


Padding requirements are described: 


(a) Camellia Padding requirement is specified in [3], 
(b)  Camellia-CBC Padding requirement is specified in [3], 
(c) Camellia-CCM Padding requirement is specified in [5], and 
(d) ESP Padding requirement is specified in [3]. 
2.2. Performance 
Performance figures for Camellia are available at [10]. The NESSIE 


project has reported on the performance of optimized implementations 
independently [12]. 


3. Modes 
This document describes three modes of operation for the use of 
Camellia with IPsec: CBC (Cipher Block Chaining), CTR (Counter), and 
CCM (Counter with CBC-MAC). 

3.1. Cipher Block Chaining 
Camellia CBC mode is defined in [6]. 

3.2. Counter and Counter with CBC-MAC 
Camellia in CTR and CCM modes is used in IPsec as AES in [7] and [8]. 


In this specification, CCM is used with the Camellia [13] block 
cipher. 
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4.  IKEv2 Conventions 


This section describes the transform ID and conventions used to 
generate keying material for use with ENCR CAMELLIA CBC, 

ENCR CAMELLIA CTR, and ENCR CAMELLIA CCM using the Internet Key 
Exchange (IKEv2) [2]. 


4.1. Keying Material 


The size of KEYMAT MUST be equal or longer than the associated 
Camellia key. The keying material is used as follows: 


Camellia-CBC with a 128-bit key 
The KEYMAT requested for each Camellia-CBC key is 16 octets. All 
16 octets are the 128-bit Camellia key. 


Camellia-CBC with a 192-bit key 
The KEYMAT requested for each Camellia-CBC key is 24 octets. All 
24 octets are the 192-bit Camellia key. 


Camellia-CBC with a 256-bit key 
The KEYMAT requested for each Camellia-CBC key is 32 octets. All 
32 octets are the 256-bit Camellia key. 


Camellia-CTR with a 128-bit key 
The KEYMAT requested for each Camellia-CTR key is 20 octets. The 
first 16 octets are the 128-bit Camellia key, and the remaining 
four octets are used as the nonce value in the counter block. 


Camellia-CTR with a 192-bit key 
The KEYMAT requested for each Camellia-CTR key is 28 octets. The 
first 24 octets are the 192-bit Camellia key, and the remaining 
four octets are used as the nonce value in the counter block. 


Camellia-CTR with a 256-bit key 
The KEYMAT requested for each Camellia-CTR key is 36 octets. The 
first 32 octets are the 256-bit Camellia key, and the remaining 
four octets are used as the nonce value in the counter block. 


Camellia-CCM with a 128-bit key 
The KEYMAT requested for each Camellia-CCM key is 19 octets. The 
first 16 octets are the 128-bit Camellia key, and the remaining 
three octets are used as the salt value in the counter block. 


Camellia-CCM with a 192-bit key 
The KEYMAT requested for each Camellia-CCM key is 27 octets. The 
first 24 octets are the 192-bit Camellia key, and the remaining 
three octets are used as the salt value in the counter block. 
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Camellia-CCM with a 256-bit key 
The KEYMAT requested for each Camellia-CCM key is 35 octets. The 
first 32 octets are the 256-bit Camellia key, and the remaining 
three octets are used as the salt value in the counter block. 


4.2. Transform Type 1 


For IKEv2 negotiations, IANA has assigned five ESP Transform 
Identifiers for Camellia-CBC, Camellia-CTR, and Camellia-CCM, as 
recorded in Section 6. 


4.3. Key Length Attribute 


Since Camellia supports three key lengths, the Key Length attribute 
MUST be specified in the IKE exchange [2]. The Key Length attribute 
MUST have a value of 128, 192, or 256 bits. 


5. Security Considerations 


For security considerations of CTR and CCM mode, this document refers 
to Section 9 of [7] and Section 7 of [8]. 


No security problem has been found for Camellia [14], [12]. 
6. IANA Considerations 


IANA has assigned IKEv2 parameters for use with Camellia-CTR and with 
Camellia-CCM for Transform Type 1 (Encryption Algorithm): 


23 for ENCR_CAMELLIA_CBC; 

24 for ENCR_CAMELLIA_CTR; 

25 for ENCR_CAMELLIA_CCM with an 8-octet ICV; 

26 for ENCR_CAMELLIA_CCM with a 12-octet ICV; and 
27 for ENCR_CAMELLIA_CCM with a 16-octet ICV. 
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